This invention relates to software program modules. More particularly, this invention relates to a method and system for recovering information contained in open files during a failure in a program module.
Despite the best efforts of software developers, software programs inevitably fail at one time or another. Unhandled failures may result in a crash, at which time the operating system terminates the, software program execution. When a program crashes, all of its state data is lost. As a result, users that were in the process of modifying a file, such as a document or spreadsheet, may lose substantial amounts of information. Information loss may create a significant amount of work and frustration to users.
To minimize the information lost as a result of a crash, several different approaches have been taken. For example, one prior art method comprises capturing a screen shot at the time of the crash. That method, however, is limited to salvaging only the information displayed on the screen at the time of the crash, if any. Thus, information that was not directly displayed is lost.
Another approach taken to recover information caused by program crashes involves saving open files automatically before the crash. More particularly, files are periodically saved in the background. This approach, however, only recovers the files as of the last auto-save. Accordingly, information that was not previously saved is lost.
A further prior art method uses exception handlers to clean up, or fix, the cause of the failure and return the user to a state before the failure. The user is then given the option of performing a normal save of the open document. For example, the application program POWERPOINT manufactured and sold by Microsoft Corporation of Redmond, Wash., has utilized such exception handlers. A crash, however, may be the culmination of a series of unexpected events that have occurred before the ultimate failure. Thus, considerable information may be lost in merely giving the user the option of doing a normal save as if the exception has never occurred.
Returning the user to the state before the failure and attempting to save the document often causes another failure while saving the document. Furthermore, if the save attempt is unsuccessful, then the modified changes in the document is lost and no other attempt is made to recover the information.
The above-described prior art methods for limiting information loss caused by a program crash suffer from varying disadvantages. Accordingly, there is a need for a method and system for saving the most recent version of an open file at the time of a program failure.
There is another need for a method and system for selecting the best version of the recovered file.
There is still a further need for using system APIs to implement the present invention that may be easily added to a software program without extensive changes to the program""s architecture.
The present invention satisfies the above-described needs by providing a method and system for recovering information during a program failure. An exception handler is provided that performs an emergency save of any file that is open at the time of the crash.
Once a failure of the program module is detected, control passes to an exception handler that attempts to minimize the amount of information that might be lost. The exception handler allows a user to attempt an emergency save of all open files that have been modified. When the program is restarted, the most recent verified version is reloaded and displayed to the user.
More particularly, once a failure occurs in an application program module, the operating system passes control to the exception handler, which may display a user interface, such as a dialog box, asking the user whether an open file should be saved.
If the user selects to save the open file, then a determination is made whether the open file has been modified from the version currently saved to disk. The reader should appreciate that this determination can also be made before questioning the user. The exception handler then saves the file to a temporary location.
The exception handler then creates a Document Recovery Persistence (xe2x80x9cDRPxe2x80x9d) in the computer registry for the file. A DRP comprises the data needed to analyze the best version available to the user subsequent to the failure. More particularly, the DRP is a record block that includes a path name, a time stamp, a process identifier, a unique numeric identifier for a version of the file, and a numeric identifier that is shared among the DRPs for each version of the file.
The program is then terminated and restarted. Upon restart, the DRP for each recovered file is accessed and compared with the DRPs, if any, for the original file and the timed auto-saved version of the file. Information in these DRPs is used to determine the best version based on the recentness and confidence level of each version. After determining which version of the file is the best, that version is then opened and displayed to the user.
In another embodiment of the invention, a user interface, such as a dialog box, may be displayed to the user providing the functionality of selecting between the different versions of the file. For example, the user may select and compare from the recovered, auto-saved, and user-saved versions. The selected version may then be stored as the original file or saved as a new file.
Although the present invention has been described above as implemented in a preferred application program module, it will be understood that alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its spirit and scope. Accordingly, the scope of the present invention is defined by the appended claims rather than the foregoing description.